Traditionally, digital certificates have been issued within a trust domain “silo” governed by a legal regime presumed to be uniform. Methods involving cross-certification between such trust domains through the use of policy mapping and a bridge certificate authority have permitted a certificate issued within one trust domain to be relied upon in another.
Another approach is to design a hierarchic Public Key Infrastructure in which a Root Certificate Authority (“Root CA”) authorizes Subordinate Certificate Authorities (“Sub-CAs”) to issue end entity certificates that can be relied upon by any other end entity authorized by Sub-CAs of the Root. One implementation of a hierarchic PKI is the IdenTrust System, which constitutes a single, uniform, trust domain with end entity certificates issued by a global network of Sub-CAs of the IdenTrust Root CA, all operating under uniform standards, policies, procedures and rules.
The motivation for the invention was to allow end entity certificates created for use within the IdenTrust System also to be used outside the System, in another trust domain, about which more below.
Most PKI systems are “open” in the sense that they: (1) rely upon local, public, law governing the making and reliance upon digital signatures and the validity of digital certificates used to authenticate them; (2) seek to bind a relying party to terms of use, substantially more specific than those of local law, via a Certificate Policy (“CP”) and/or Certification Practices Statement (“CPS”) typically posted on a web site pointed to by a URL embedded in the certificate, which a relying party is deemed to have accepted in virtue of the fact of reliance upon the certificate, in a manner analogous to “shrink-wrap licenses” in the world of software; and (3) rely upon methods of certificate validation that can be performed by any member of the public. Such open systems rely in part on public, local law, and in part on the presumed enforceability of the CP or CPS against the relying party, who is not in fact contractually bound to them.
The IdenTrust System is a closed contractual system, in which every subscriber and relying party is bound to a customer agreement which contractually specifies the rules under which digital signatures are agreed to be made and relied upon and the digital certificates are agreed to be valid. Local, external, public law, such as that governing sovereign recognition of digital signatures and digital certificates in any particular jurisdiction is viewed as irrelevant to the closed contractual system, so long as the customer agreements are locally enforceable, which is determined through legal analysis when the certificates are to be offered in a new jurisdiction. The certificate architecture of the system reinforces its contractual structure: a person seeking to rely upon a certificate issued within the system can do so only after receiving a positive response to a certificate validation request the party seeking to rely has digitally signed with a private key he possesses solely by virtue of being bound to a customer agreement with a Participant.
The IdenTrust System is a hierarchic PKI in which the IdenTrust Root CA licenses uniform policies, procedures, and technological specifications to its Participant financial institutions, binds them to uniform rules, and requires that their customer agreements contain uniform terms. The IdenTrust Root CA issues certificates to its participant financial institutions (each a “Participant”), whose Sub-CAs of the Root, in turn issue end entity certificates to individual certificate holders employed by customers of the Participants. Because of the uniformity of the rules and procedures throughout the system, every certificate issued by the Sub-CA of any Participant is as reliable and trustworthy as any other certificate issued by the Sub-CA of any other Participant, even if the Participants or the customers are in different countries governed by different laws.
However, local customers often want to possess, or to rely upon, certificates issued under some local policy regime. For example, certificates that are “Qualified” under the law of a European country that complies with the EU Digital Signature Directive are often commercially preferred for certain purposes in such a country. Often such certificates can be validated via a method open to the public, such as via reference to a Certificate Revocation List generated by the CA and posted on its web site or accessible through a distribution point identified in the certificates. Accordingly, it is advantageous to the CA to be able to issue certificates that can be used both within the contractual, global system, such as the IdenTrust System, and outside it under applicable local law. Such dual use is both internal to the closed IdenTrust System at one moment of reliance and “External Use” under the alternate trust domain at another moment of reliance.
Certificates to be used for a specific purpose are typically issued within a designated trust domain. In one deployment, for example, certificates issued to certain government employees were required to be issued under the Certificate Policy applicable to that trust domain. Use of the invention permitted the issuance to said employees of IdenTrust certificates each such person could use for dual purposes, such as both access to government buildings and for electronic banking.
The operation of a PKI, and the distribution of digital credentials, readers and associated software and hardware can be expensive. It is highly advantageous to a CA, and to its subscribers and relying parties, to permit its certificates to be issued from a single platform and on a single token, but used or relied upon in multiple trust domains. This spreads the cost of the infrastructure investment across all of the trust domains and the applications that may be specific to each of them.
Accordingly, a need arose to develop a method by which a given certificate could be alternately bound to more than one policy regime (or legal, regulatory, or contractual structure) in different trust domains, at the election of the relying party at the time of reliance. This method can be generalized to any alternative trust domains.
It is crucial that there never be any doubt as to which trust domain is being bound to the certificate at any given moment of reliance. Such domains often have varying rules governing liability, recourse, and dispute resolution, and ambiguity as to which rules govern reliance upon a multi-domain certificate at any moment would be fatal to interoperability of the certificate across the trust domains. The invention assures that one and only one trust domain is bound to a certificate at any given moment by requiring that the relying party, at the moment of reliance, use a certificate validation mechanism unique to that trust domain, and thereby demonstrate its choice of the associated policy regime.
An alternative means of using a certificate in multiple trust domains that has been widely deployed in the prior art is the use of a bridge. A bridge is intended to connect the silos of multiple trust domains like a causeway connecting islands. A bridge comprises a Certificate Authority that issues “cross-certificates” to other CAs and receives corresponding cross-certificates from such CAs so that a relying party in one trust domain can rely upon a certificate issued by a CA in another. Thus, if a relying party has CA #1 as its trust anchor, and wishes to rely upon a certificate issued by CA #2, if the bridge CA has exchanged cross-certificates with CAs #1 and #2, then the relying party whose trust anchor is CA #1 can trust CA #2 as an alternate trust anchor, and vice versa. In an architecture relying upon certificate path discovery and validation, the cross-certificates permit the relying party in question to discover the certificate path between the subscriber's certificate (issued by CA#2) and the relying party's ultimate trust anchor, CA #1. The cross-certification process typically requires a painstaking, and therefore expensive, mapping of the certificate policies of each of the cross-certified CAs to those of the bridge CA (to determine whether they meet common standards), as well as contracts between each CA and the Bridge CA establishing certain common understandings. Problems of cross-certification can include “transitive trust,” which can extend the opportunity of reliance upon a certificate to unintended relying parties. See, e.g., Fisher, James L., Side-Effects of Cross-Certification, http://middleware.internet2.edu/pki05/proceedings/fisher-cross_cert.pdf. The invention permits a single certificate to be trusted in multiple trust domains without policy mapping or cross-certificates, and permits a closed system to remain closed, regardless of the reliance upon the same multi-domain certificates outside the closed system.